A typical communication session generally involves a persistent interactive exchange of information between two or more communicating entities (e.g., devices, applications, etc.), which can also be referred to as nodes. In the current RESTful approach, there is no real persistent connection. Instead, communication is performed via on-demand request and response messages. For example, a communication session may be established at a certain point in time, and torn down at a later point in time based on various circumstances (e.g., after the session times out or when one of the entities decides to terminate the session). A communication session often involves the exchange of multiple messages between entities and is typically stateful, which means that at least one of the communicating entities needs to save information about the session history in order to be able to maintain the communication session. Example information that may be saved includes security context such as credentials, identifiers, etc. Communication sessions may be implemented as part of protocols and services at various layers in a network protocol stack. As an example, FIG. 1 shows communication sessions established between network nodes at the transport protocol layer, application protocol layer, application service layer, and between applications.
A machine-to-machine (M2M) service layer is an example of one type of application service layer specifically targeted towards providing value-added services for M2M type devices and applications. For example, an M2M service layer can support Application Programming Interfaces (APIs) that provide applications and devices access to a collection of M2M centric capabilities supported by the service layer. Example capabilities include, without limitation, security, charging, data management, device management, discovery, provisioning, and connectivity management. FIG. 2 depicts the common services function (CSF) that is specified by the oneM2M specifications.
Referring to FIG. 2, the illustrated functions (capabilities) are made available to applications via APIs that make use of message formats, resource structures, and resource representations defined by the M2M service layer. A growing trend in the standardization of M2M network technologies has been the standardization of the M2M Service Layer. Examples of the standardization of the M2M Service Layer include the various oneM2M specifications.
An M2M service layer session refers to a communication session established between a M2M service layer instance and an M2M application or another M2M service layer instance. An M2M service layer session can consist of an M2M service layer state related to connectivity, security, scheduling, data, context, etc. This state can be maintained by the M2M service layer, an M2M application, or a combination thereof. An M2M service layer session can be layered on top of one or more underlying lower layer communication sessions. In doing so, a session state (e.g., security credentials, congestion information, etc.) can be shared and leveraged between the different sessions. In addition, an M2M service layer session can support persistency with regard to lower layer sessions such that the M2M service layer session can persist and be maintained independently from lower layer sessions being setup and torn-down. Examples of lower layer sessions that a M2M service layer session can be layered on top of include, but are not limited to, application protocol layer sessions (e.g., HTTP or CoAP) and transport protocol layer sessions (e.g., TCP and/or UDP), which may be secured using protocols such as, for example, Transport Layer Security (TLS for TCP) or Datagram Transport Layer Security (DTLS for UDP).
With respect to current approaches to oneM2M service layer security, when oneM2M endpoints communicate with one another in a secure manner, the nodes and intermediate nodes establish a security association with one another in a hop-by-hop manner. Each hop may have a separate security association that is independent from other hops. Hop-by-hop security associations may be established by means of symmetric keys, by using certificates/raw public keys, or by a bootstrapping process that may be performed by a direct process or remotely by using the services of a device manufacturer or service provider. Also, in accordance with the current version of the oneM2M Security Solution, one M2M-TS-0003 Security Solutions, “At the service layer level, the security association establishment results in a TLS or DTLS session which protects messages being exchanged between adjacent AE/CSE, i.e. hop-by-hop.”
FIG. 3 shows an example of Hop-by-Hop (HbH) security associations between entities by means of (D)TLS secure associations using credentials that are unique and confidential to the two communicating entities that are involved. As shown, a first application entity (AE1) and a first hosting common services entity (HCSE1) create a secure (D)TLS connection based on HbH credentials (H1), which are shared by the two entities (AE1, HCSE1). Similarly, HCSE1 and an intermediate node (IN-CSE1) have setup a secure (D)TLS connection using H2 credentials. As shown, credentials H3 are used for creating a (D)TLS connection between IN-CSE and a second HCSE (HCSE2), and credentials H4 are used to create the secure connection between a second AE (AE2) and HCSE2.
Still referring to FIG. 3, if HCSE1 wanted to communicate information to AE2, then the information is first sent through the (D)TLS connection between HCSE1 and IN-CSE. The information is then extracted after being decrypted by the (D)TLS application, and then processed at the service layer and sent re-packaged through a separate (D)TLS tunnel between IN-CSE and HCSE2. The HCSE2 processes the message and then re-tunnels the message through a different secure tunnel between HCSE2 and AE2. As shown in the illustrated example, the communications between any two HbH entities is secured by (D)TLS, and therefore breach in confidentiality or integrity of messages that are in transit between the Entities may be difficult because they are protected by (D)TLS connection, however, the messages might not be protected at the entity where it is being processed at the service layer (SL) before being forwarded to the next hop.
Turning now to object security initiatives, object security initiatives have been studied and standardized within the IETF, and implemented for various single sign-on solutions (e.g., OpenID). As stated in the IETF RFC 7165, Use Cases and Requirements for JSON Object Signing and Encryption, “Many Internet applications have a need for object-based security mechanisms in addition to security mechanisms at the network layer or transport layer. For many years, the Cryptographic Message Syntax (CMS) has provided a binary secure object format based on ASN.1. Over time, binary object encodings such as ASN.1 have become less common than text-based encodings, such as the JavaScript Object Notation (JSON)”. Different security aspects based on JSON are specified in 1) JSON Web Signature, IETF-RFC 7515 for integrity/authenticity; 2) JSON Web Encryption, IETF-RFC 7516 for confidentiality; 3) JSON Web Key, IETF-RFC 7516 for credential representation; and 4) JSON Web Algorithms, IETF-RFC 7518 for algorithms.
As described above, existing approaches to security within oneM2M networks, for example, are limited. For example, content might only be protected while the content is in transit (not at rest) between entities that trust each other.